Secure communication method and system using network socket proxying

专利摘要:
The present invention relates to the telecommunications sector and, in particular, to the field of telematics. More specifically, the invention describes a method and system for defining an improved network technology that can be used for communication and to operate secure communications between processes, based on the secure proxying of local area network sockets that may be between different devices. In particular, the system and method describe how socket proxies are established and managed between devices and how the security of said socket proxies in the local area thereof is enhanced and operated using security contexts. These contexts are configured based on privilege separation and local packet marking and filtering, and they allow applications to delegate all aspects relating to the security of the communications in the present invention.
公开号:ES2794723A1
申请号:ES201990044
申请日:2018-06-03
公开日:2020-11-18
发明作者:Hoz Diego Jorge David De
申请人:Hoz Diego Jorge David De；
IPC主号:

专利说明:

[0003] TECHNICAL SECTOR
[0005] The present invention relates to the telecommunications sector and particularly to the telematics area.
[0007] BACKGROUND OF THE INVENTION
[0009] The constant and growing number of devices and automation derived from the rise of the Internet of Things (IoT), together with the take-off of Industry 4.0, highlight the importance of simplifying the control of communications and the management of their security. Previously, the number of unattended devices in any type of project was significantly lower, which presupposed a direct interaction between the devices with the end user or the network operator to a greater or lesser degree. However, the high number of elements that make up these networks and their forecast of exponential growth over time modifies this type of direct interaction, since it would be unfeasible in most cases and goes against a generalized automation trend. For this reason, it is required that certain security aspects work in a solid, standardized and reliable way to avoid, for example, a network supervisor having to continuously analyze the status of each device element by element; at the same time that scalability and interconnectivity are favored, enhancing the functionalities of this technology.
[0011] Security in communications in the IoT, particularly in high-level devices with the ability to be updated, is generally considered as a feature that must be provided by the software / firmware of each device in conjunction with the software platform that is responsible for managing and administering them. and from which resources and services derive. Regardless of the communications protocol used for this, the current solution used involves embedding the communications authentication and encryption software in the device's own firmware or in the main application that it uses. Said software provides a cryptographic protection of the communication channel to avoid security attacks at some intermediate point of the same avoiding, among others:
[0012] • That the information that is exchanged can be heard (eavesdropping).
[0013] • That the information exchanged can be modified, replicated, its order altered or falsified without this fact being detected by the recipient of the communication (tampering).
[0014] • That the receiver with whom the sender of the communication communicates impersonates the identity of the authentic receiver of the same, and this usurper agent, in turn, impersonates the sender of the communication facing the receiver (man in the middle).
[0016] This type of cryptographic protection is achieved, in most cases, using a security framework in the development of applications that uses Transport Layer Security (TLS) or some proprietary security protocol. In both cases, a modification that requires updating algorithms or certain configurations of security aspects usually requires updating the entire application and, in many cases, also the firmware of the device. Some examples of such implementations are on devices that use COAP, MQTT, HTTP, or HTTP / 2 with security.
[0018] This type of design, in which the security protocol is integrated into the software, leads to the need to keep the development teams of this software active for all its versions and for each device model that currently makes use of it; For this reason, manufacturing companies tend to limit the support they give to the products they sell in time, encouraging them to replace the complete device with its new version in case their firmware or application security becomes obsolete. In the medium term, this idea frequently does not represent a real alternative for the final consumer; since it must consider as cost, not only the amount of the new devices, but the replacement of the old ones by the new ones, training for employees and updating of its internal processes, among others.
[0020] The lack of anticipation in these costs on the part of companies that manufacture IoT technology leads consumers to choose to continue working with obsolete devices in aspects related to their security. On many occasions, these devices do not need to handle sensitive information (certain sensor networks) so, even if these devices are recognized as vulnerable, the end user chooses to keep them since they do not pose any real risk. All this leads to a scenario in which third-party critical infrastructures end up running the risk of being threatened (commonly through denial of service or DoS attacks) by botnets created precisely from these vulnerable IoT devices that have managed to be infected with malicious code, but they apparently continue to function normally.
[0021] EXPLANATION OF THE INVENTION
[0023] The present invention is characterized by independent claims and dependent claims set forth exemplary embodiments of various aspects of the invention.
[0025] The present method and system presented provide solutions for the problems of the state of the art by proposing a secure communication system based on proxification that allows the applications of the devices to delegate the security functionalities in independent and stand-alone software modules that can be updated. without affecting the rest of the software of the devices. This objective is achieved by combining a secure communication based on proxifications between devices together with a control of local communications, using for the latter security contexts that allow restricting access to said proxifications depending on the origin of the communication. This strategy makes it possible to greatly simplify the development of applications and the maintenance of security in the medium and long term, even when the support of these applications is no longer available. This is possible thanks to the fact that the system described in the invention is not part of the applications and can be updated without affecting them.
[0027] To facilitate understanding of the invention, the interpretation of the most relevant concepts used in this document is attached:
[0028] • Proxify: Action of offering the service or resource provided by a network socket in another different network socket, this socket being able to be located in a remote device.
[0029] • Proxification or socket-proxy: Result of the action of proxifying in which a new network socket is defined, through which it is possible to access the source socket of the proxification in a transparent way and obtain the resources or services offered by it. .
[0030] • Proxy-firewall server: (111) A software module that is configured to:
[0031] o Receive session establishment requests from other devices through a secure protocol through a stand-alone proxy server.
[0032] o Configure strict and broad security contexts through system calls (427) to the network framework of the device_A operating system.
[0033] o Process so-called "socket-proxy" proxification requests through established sessions or system calls from local processes.
[0034] o Monitor access to local sockets through access monitors.
[0035] o Manage the security updates of the devices with which you maintain a connection.
[0036] o Establish, through system calls to the network framework, the protection of the local sockets used in the proxifications on device_A.
[0037] Direct proxification: (114) A type of proxification that occurs when the socket-proxy resulting from it is generated in the device that initiates the session for it, and that socket-proxy offers resources or services from a socket of the device to where session establishment is directed.
[0038] Reverse proxification: (115) A type of proxification that occurs when the resulting socket-proxy is generated on the device where the session establishment is directed for it, and this socket-proxy offers resources or services from a socket of the device that initiates the session establishment.
[0039] User space: (418) Memory area where operating system user processes operate.
[0040] Kernel space: (419) Memory area where the kernel processes of the operating system operate exclusively.
[0041] User environment: Environment of the operating system in which the settings and privileges associated with the user of said environment apply or have effect.
[0042] Network framing: (107) (420) Set of tools that interact with the operating system or that are part of it and that allow configuring the treatment received by the communication packets that are transmitted from user space to kernel space and vice versa.
[0043] Protected socket: Local network socket whose access is restricted based on filtering rules of the device's operating system network framework.
[0044] Security context: Local network environment characterized by access permissions to certain protected network sockets.
[0045] Strict security context: Security context applied between a protected socket and the user space of a specific user of the same operating system. In the present invention, a strict security context is generated when a permission_A ^ü is applied in a socket-proxy of device_A by means of rules of the network framework. They are also generated on device_B when the rules described in profile_B ^{A are} applied.
[0046] Broad security context: Security context applied between a protected socket and the user space of multiple users of the same operating system belonging to the same group. In the present invention, a wide context of security is generated when one applies permiso_A ^G in a protected socket.
[0047] Agent: a software module that acts as an agent for the proxy-firewall server from a remote device. This software is configured to:
[0048] o Initiate communication session establishment requests towards the proxy-firewall server through a secure protocol.
[0049] o Make direct and reverse socket proxification requests.
[0050] o Establish, through system calls to the network framework, the protection of the local sockets used in the proxifications on device_B.
[0051] The agent is named in different ways depending on the device it is on:
[0052] o Agent_A: (408) if it is on device_A. It is only necessary on device_A if it requires proxification with other devices_A. o Agent_AF, if it is on a device_AF.
[0053] o Agent_B: (109) if it is on a device device_B.
[0054] Proxy client: (112) (409) Complementary software module of any agent that implements the secure communications protocol used to establish the communications session and to carry out proxifications, both direct and reverse.
[0055] Proxy server: (113) (422) Complementary software module of the proxy-firewall server that implements the secure communication protocol used for session establishment and that receives and processes proxies requests; both direct and reverse.
[0056] Connection-broker: (121) (415) Software module used to maintain a record and control over the proxifications made and the accesses to them on device_A. It also takes care of periodically closing inactive accesses.
[0057] D ispositive_A: (106) (405) Hardware element that houses at least: a proxy-firewall server, a connection-broker, a network framework, a database, a profile_A and optionally an agent_A. In the present invention, if any process requires two devices_A, the device on which the main procedure is described is constituted as device_A and the other as device_AF.
[0058] D ispositive_AF: Hardware element equivalent in functionalities to a device_A. The reason for differentiating it as device_A is to facilitate the explanation of the communications that may occur between two devices_A.
[0059] Device_B: (101) Hardware element that houses at least one network framework, one agent_B and one profile_B ^A. In case of also hosting a proxy-firewall server, the operation configuration of this software module is also included in profile_B ^A , as this proxy-firewall server will have reduced functions and aimed at extending the control that the proxy-firewall server of device_A It has the software modules of the device_B, particularly for update processes.
[0060] Database: (122) (414) Software module configured to save and consult different types of records used in the invention, among which are: socket_register, access_register, access_register_A, permission_A ^U and permission_A ^G.
[0061] Profile_B ^A : Agent configuration profile of device_B to configure the connection session to the proxy-firewall server of device_A. This profile also contains the credentials to connect to device_A using the user account user_A ^B of the operating system of device_A. Likewise, it also includes information related to the ability of user_A ^B to request proxifications on device_A, said ability being validated by the proxy-firewall server after each proxy request.
[0062] Profile_A: Configuration profile of the proxy-firewall server and the connection-broker of device_A.
[0063] Profile_UA ^AF : Configuration profile for the agent of device_A to configure the connection session to the proxy-firewall of device_AF. This profile belongs to user_A and it also contains the credentials to connect to device_AF using the user account user_A ^AF of the operating system of device_AF. This profile also contains information regarding the ability of user_A ^AF to request proxifications in device_AF, said ability being validated by the proxy-firewall server of device_AF after each proxification request.
[0064] User_A ^B : User of the operating system of device_A that is used by agent_B when it connects to device_A using the credentials defined in profile_B ^A.
[0065] User_A ^AF : User of the operating system of device_AF that is used by agent_A when it connects to device_AF using the credentials defined in profile_UA ^AF .
[0066] Socket_A: (123) Protected socket of device_A that offers resources or services to local processes and remote devices by means of direct or reverse proxies. Socket_B: (118) Protected socket of device_B that offers resources or services to remote devices through a reverse proxy socket on device_A.
[0067] Socket_AF: Protected socket of device_AF that offers resources or services to local processes and remote devices through direct or reverse proxies. Alias: identifier referring to a specific socket that is used to name the socket of a device. It is important to note that the alias refers to the original socket that offers a service or resource. All your proxifications will inherit this alias, which can be of several types:
[0068] o Alias_B: if the alias refers to a socket_B of a process on device_B. o Alias_A: if the alias refers to a socket_A of a process on device_A. Id_DispSocket: Variable relative to the socket register of a protected socket that identifies, together with the socket alias of said register, the protected socket of the device. This variable refers to the id of the device with the process that originated the socket that offers the resource or service and can store three types of identifiers:
[0069] o An id_B, if the alias of the access_register refers to a socket_B.
[0070] o An id_AF, if the socket of the access_register communicates with a socket_proxy.
[0071] o An id_A, if the alias of the access_register refers to a socket_A.
[0072] Id_DispProxy: Variable relative to the socket_register of a protected socket that identifies the id of the device with which a session is maintained in order to access the socket referred to by the alias and the ID_DispSocket of the register. In the particular case that the socket_register refers to a proxy-socket of another proxy-socket, the id_DispSocket will refer to the device id of the second proxy-socket.
[0073] Socket_type: Variable relative to the socket_register of a protected socket that identifies the type of socket referred to by said register, which can be reverse socket-proxy, direct socket-proxy or socket_A. Reverse and direct socket-proxies can also be of type socket_A, socket_B and socket-proxy, the latter indicating that the protected socket is a proxy for another socket-proxy.
[0074] Socket_Record - A type of record from device_A relative to a protected socket. It is stored in the connection-broker database and comprises of:
[0075] o A variable named socket, which stores the protected socket referred to by this socket_register.
[0076] o An alias of the socket that this socket_register refers to.
[0077] o An id_DispSocket relative to the device with the socket referenced by the alias. o An id_DispProxy that identifies the device to which the session leads in which the protected socket is generated.
[0078] o A type_socket.
[0079] Con_Id: Identifier of the mark made in the network traffic related to communication with a protected socket. This id determines the user account or user group source of said communication, registered in the database of the connection-broker with destination that specific protected socket.
[0080] Id_Usuario: Identifier of a user or of the account related to the same in the operating system of device_A. This identifier uniquely represents the user and his user account, and these two concepts can be used interchangeably in scenarios related to the security contexts of device_A.
[0081] Last_activity: Variable relative to an access_log of a user_A to a proxy-socket that defines the last moment in which there was activity related to the protected socket referred to in the access_log.
[0082] Access_record: a type of record related to a user account of the operating system of device_A and that is generated for each access granted to a protected socket of the direct or reverse socket-proxy type, which comprises:
[0083] o A con_Id, which stores the id of the access relative to this record.
[0084] o A variable named "socket" that stores the protected socket to which access is granted and is made up of the local network address and port.
[0085] o An id_Usuario, which stores the id of the user to whom access is granted.
[0086] o A last_activity that initially saves the moment the record is created and is subsequently periodically updated (if applicable) by the access monitor.
[0087] Access_Record_A: a type of record related to a group of users of the operating system of device_A, which is generated for each access granted to a protected socket of type socket_A, and which comprises:
[0088] o A con_Id, which stores the id of the access relative to this record.
[0089] o A variable named "socket" that stores socket_A.
[0090] o A group_id, which stores the group id of the user to whom access is granted. Access monitor: software module used to maintain a record and control over the proxifications made and the accesses to them on device_A. This can work in two ways:
[0091] o Periodically checking if there is traffic related to a protected socket, and in which case, it updates the last_activity status of the relevant access_register.
[0092] o Periodically updating the status of the last_activity of the access_log of the accesses that it monitors to guarantee accessibility to the respective protected sockets while the process that requested the accesses is still running.
[0093] When an access monitor ends, either because there is no activity for a certain period of time or because the process responsible for proxies has ended, the access_registers that it was in charge of are no longer updated. This causes the inactivity of those access_registers to increase and eventually they are closed by the connection-broker. When this happens, the proxy-firewall server is notified to delete the relevant dialing rules and close the accesses relative to the deleted access_logs. If the deleted access_registers referred to a proxification between a device_A and a device_AF, the connection-broker also removes the socket_register and the permission_A ^U relative to each access_record.
[0094] Perm iso_A ^u : This type of permission is used to grant user_A access to a protected socket that is a proxy-socket through a strict security context. It is saved as a record in the connection-broker's database and this record comprises the following variables:
[0095] o id_Usuario, which stores the id of the operating system user of device_A. or alias, which stores the alias of the protected socket that is proxied as socket-proxy on device_A.
[0096] o id_DispSocket, which stores the id of the device with socket_B or socket_A relative to the alias of the socket that offers the resource through the socket-proxy.
[0097] Perm iso_A ^o : This type of permission is used to grant access by a group of users from device_A to socket_A through a broad security context and includes the following variables:
[0098] o id_Grupo, that stores the id of the group of users of the operating system of the device_A to which the access permission is granted.
[0099] or alias, which stores the alias of socket_A.
[0100] or socket, which stores the value of socket_A.
[0101] Sandbox-jail: Set of packet filtering rules that configure an access protection to the protected sockets. It also restricts the destinations of communications.
[0102] Access granted to a protected socket: It is called access granted to a protected socket, or simply "access granted" to the configuration of a security context that enables a user of an operating system to access a local protected socket. Single access Granted is applicable to any number of concurrent connections made from that user's account to the protected socket referred to by that access.
[0103] End application: Application used by an end user.
[0104] • End user: Natural person who requires a resource through an end application or requests a service from a platform.
[0105] • Platform: (105) (413) Software module that allows monitoring and managing the information and services that are offered by other devices on the network. This information and services offered by the platform are mainly obtained from devices_B. The main function of the platform is to process these data and services to make them available to end users in the form of their own resources. On the other hand, it can also act directly on the network elements that it manages to modify its configuration or require actions from them using the local protected sockets to which it has access.
[0106] • Host: Physical or virtual machine with a multi-user operating system that hosts one or more platforms.
[0107] • Proxy: (410) (423) Software module used by each type of protocol used by communication requests directed to a protected socket that does not use the same type of communication protocol as the one used by the request originating process. The proxy works as a translator between protocols to make communication transparent and its functions include the following:
[0108] o Authenticate the communication requests with credentials of some user of the operating system of device_A who has permission_A ^U or who belongs to a group with permission_A ^G that allows access to the protected socket.
[0109] o Enable an access_register if necessary through system calls. o Remove the communication authentication credentials so that it can be sent to the protected socket and said authentication process is transparent to the latter;
[0111] This invention allows processes to communicate with each other using proxifications without having to directly rely on security protocols. In this way, the two processes that need to communicate with each other can carry out said communication locally in a security context that allows said communication to be also transparent thanks to proxification.
[0113] Security contexts:
[0115] Communication between processes through proxification between two devices consists of three segments: The intermediate segment, which communicates both devices and is protected by the communication session between the agent and the proxy-firewall server; and the two segments local, which communicate each end of the proxification with the respective processes. Each of these two segments are vulnerable if a security context is not applied, since any process can access the ports that are listening, which is insecure since the communicating applications delegated all security responsibility to it. agent and proxy-firewall server. For this reason, the present invention defines the concept of protected socket and security context.
[0117] Security contexts consist of rules applied through the network framework of two types: Dialing rules and network traffic filtering rules. The rules, in turn, can be general or priority and their combination makes it possible to protect local communications between processes and proxifications. These contexts are a type of sandbox-jail that prevent communications with sockets other than those found within it from being processed.
[0119] The definition of the marking and filtering rules that configure the protected sockets and the security contexts use two elements: The local socket destination of the communication and the user or group whose process is the source of the communication of network packets. This last piece of information must be inserted into the network traffic by marking the packets since, in most network protocols, there is no translation of this information to it. Therefore, it is necessary to use a network framework that configures the operating system to enter this data in the form of markup. On the other hand, it should be clarified that trying to identify the origin of the communication through the source socket is generally complicated because applications use a different socket each time they request to establish a communication. The security context is therefore defined with the destination socket and the origin user id or the origin user group of the communication. This information is translated into a connection identifier to the destination socket that is added to each network traffic packet in order to identify the communication flow.
[0121] Once the marking procedure for allowed communications is defined, the filtering procedure is simple: protected sockets must only be accessible by communications marked by the operating system based on the rules of the network framework and said communications can only be local and belonging to a reserved and protected local address range. In this scenario, the communication vulnerability is restricted to the possibility that a user or process can obtain elevated privileges that allow it to control the network framework.
[0122] Protection of the reserved address pool:
[0124] A pool of local addresses of device_A is reserved in profile_A specifically for this system. These addresses are protected when starting the operating system of device_A by the network framework at the request of the proxy-firewall server by means of the following general rules:
[0126] • A general rule of packet marking that determines to eliminate any possible marking of network packets in any communication, produced between local sockets of device_A, with local addresses belonging to the reserved local address pool.
[0127] • A general rule of packet filtering that determines to discard any packet with source and destination a local socket of device_A that lacks a mark as long as any of the sockets uses a local network address belonging to the reserved local address pool.
[0128] • A general rule of packet filtering that determines to discard any packet with a local address from the local address pool reserved for this method that originates or ends with a non-local address.
[0130] In addition, during the startup sequence of the operating system of device_A, each access_register and permission_A ^U of the database must be performed relative to each register_socket whose socket_type is socket-proxy, and the deletion of the register_socket itself; since these access_registers and socket_registers are relative to proxifications between devices_A and are considered temporary.
[0132] Secure communication method by network socket proxification:
[0134] The following is the method that enables secure interprocess communication through network socket proxifications. To do this, initially the protected sockets are established on device_B and device_A and all of this includes the following actions:
[0136] • During device_A startup, the proxy-firewall server enters some dialing and filtering rules through the network framework to the operating system of device_A to protect the pool of addresses assigned in profile_A. These general rules include:
[0137] o Eliminate any possible marking of network packets generated by the processes in any communication, produced between sockets of device_A, with network addresses belonging to the pool of local addresses reserved for this method.
[0138] o Discard any packet with source and destination a local socket of device_A that lacks a mark, as long as any of the sockets uses a local network address belonging to the pool of addresses reserved for this method.
[0139] o During device_B startup, agent_B enters at least one rule to the network framework of device_B operating system to protect each socket_B defined in profile_B ^A. This general rule consists of discarding any network packet that has a non-local source address and the destination is one of the sockets_B.
[0140] o Enter, during the startup sequence of the operating system of device_A and through a network framework of the latter, a general rule of packet filtering by the proxy-firewall server that determines to discard any packet with origin or destination a local address of the local address pool reserved for this method that has a non-local address as source or destination.
[0142] Once the address pool protection rules have been established on device_A, sockets_A are registered in the database that are not already there and the relevant dialing rules are applied that define the broad security contexts that correspond in the device_A to grant permanent access to user groups of device_A that are defined in profile_A. All this includes the following actions:
[0143] • The entry, if it does not exist, during the startup sequence of the operating system of device_A of a record_socket in the database of device_A relative to each socket_A of device_A collected in profile_A, each record_socket containing information that includes:
[0144] o The id_DispSocket, which in this case would be the id_A.
[0145] o The id_DispProxy, which in this case would also be equal to id_A.
[0146] o The alias, which in this case would be the same as the one used by socket_A to be registered.
[0147] o The socket, which in this case would be equal to the local socket used by process_A for socket_A defined in profile_A.
[0148] o The type_socket, which in this case would be equal to "socket_A".
[0149] • The entry, if they do not exist, of the permissions_A ^G and of each record_access_A as contemplated in the profile_A.
[0150] • The entry of priority dialing rules for each access_A record of each socket_A permanently granted to the user groups of device_A as each one is defined in the form of permission in the connection-broker database.
[0152] After this, the proxy-firewall server verifies through the connection-broker that in the database there are no valid accesses relative to socket_proxy-type socket_registers. If it exists, it will delete each access_record associated with said socket_record including the socket_record itself. These registers are relative to proxifications between device_A and devices_AF, they are considered temporary and during the startup of the operating system of device_A they should be deleted.
[0154] The process continues when the proxy-firewall server of device_A receives a request to establish a session from agent_B to perform proxifications, all of which include the following actions:
[0156] • Establish a secure communications session that allows socket proxifications between device_A and device_B, where the first uses a proxy-firewall server that hosts and the second uses an agent_B that initiates the establishment of said session using a proxy client stand-alone that implements a secure communication protocol using configuration data and credentials of user_A ^B defined by his profile_B ^A. Thus, device_B establishes the session with device_A using the account user_A ^B.
[0157] • Subsequently, proceed with the establishment of direct proxifications. These allow access to each socket_A required from device_B. These proxifications are requested by agent_B according to profile_B ^A and are protected by the secure protocol used in the communication session between agent_B and the socket-proxy server.
[0158] • Establish reverse proxifications. These allow each socket_B to be accessible by the applications on device_A locally as long as the user of the operating system that executes them has permission to do so. Each socket_B to be proxied is also defined in profile_B ^A.
[0159] • Register the reverse proxifications in a database of a connection-broker of device_A generating a register_socket for each one of them.
[0160] Once this method has been followed, the processes of device_B can access each locally proxied socket_A and the processes of device_A that have permission_A ^U can access the reverse proxy-socket once they request the resolution from the proxy-firewall server of device_A and the relevant strict security contexts are configured.
[0162] BRIEF DESCRIPTION OF THE DRAWINGS
[0164] Different aspects of possible embodiments of the present invention are illustrated by way of example in the accompanying drawings and diagrams.
[0166] • Figure 1: Example of realization of a device_B and a device_A in which the agent_A and the socket-proxy server maintain a session through which proxifications are made. Through these proxifications, process_B and the platform can communicate with each other.
[0167] • Figure 2: Example of establishing a direct proxification of a socket_A on a device_B and a reverse proxification of a socket_B on a device_A.
[0168] • Figure 3: Example of communication of process_A with a protected network socket.
[0169] • Figure 4: Example of realization of a device_A.
[0170] • Figure 5: Example of URL used in requesting a resource from a socket protected through a proxy of device_A.
[0171] • Figure 6: Example of request for direct proxification of protected sockets of a device_AF by a process_A of a device_A.
[0173] DETAILED DESCRIPTION OF THE INVENTION
[0175] The preferred embodiment and various examples of the embodiment of various aspects of the present invention are described below with reference to the attached figures to illustrate its operation in different scenarios.
[0177] Preferred embodiment of the invention:
[0179] An example of the embodiment of the invention can be found in Figure 1. This embodiment is oriented to an IoT ecosystem. In this scenario, an example of device_B (101) would correspond to all those IoT devices in the ecosystem that are considered nodes of the ecosystem. In this example, the devices can work with firmwares or operating systems (102) of the POSIX (Portable Operating System Interface) type. An example of this type of operating systems are those of the Linux family or some of its variants. In any case, they have a kernel that can make use of a network framework such as Netfilter, which can be in the Kernel or be loadable through external modules and through which marking and filtering rules are entered (103). This device_B has at least one process_B (104) that develops the main functionality of the device and that requires communication with management software such as a platform (105) of a device_A (106).
[0181] In the presented IoT ecosystem, an example of device_A would correspond to the IoT host to which the IoT nodes connect. In this example, device_A also has a POSIX-type operating system and also of the Linux family, but this is something that is not essential, since being POSIX-type operating systems, interoperability between them is feasible. In any case, the operating system of device_A, being also from the Linux family in this example, also has a kernel with Netfilter framework (107) through which marking and filtering rules (108) are also entered. The operating system of device_A, when used in an IoT host, must be multi-user and capable of separation of privileges. That way, each device_B that connects to it can use a different operating system account on device_A. This enables Netfilter to differentiate communication flows and create security contexts that extend communication protection in the local area for each device.
[0183] Security in communications between device_A and device_B is provided by an agent_B (109) of device_B that establishes a secure session (110) with a proxy-firewall server (111) of device_A. This secure session uses a security protocol that runs between a stand-alone proxy client (112) and a stand-alone proxy server (113). The first is part of agent_B and the second, of the proxy-firewall server. The session they establish between them allows proxies between the two devices. An example of this type of protocol is SSH, which has implementations that function as a stand-alone proxy client and a stand-alone proxy server as required in this example. Some examples of these implementations are OpenSSH and Dropbear.
[0185] Agent_B uses the established session to proxify connections between both devices as specified in profile_B ^A used by said agent to establish the session. In this way, and according to the information contained in said profile, agent_B creates the corresponding socket-proxies (114) on device_B and reverse socket-proxies (115) on device_A. The establishment of proxifications, therefore, can done in both directions, even if the session between the agent and the proxy-firewall server is started by agent_B.
[0187] Once the proxifications are established, both the process_B and the IoT platform can communicate using socket-proxies. If communication is initiated by process_B, it will use the local direct proxy socket (114) generated by agent_B to communicate with socket_A (123). Such secure communication has three parts:
[0189] • The first (116) is a local segment that comprises the communication between process_B and the direct proxy socket of agent_B. This communication segment is protected by the strict security context configured by agent_B when booting the operating system of device_B through Netfilter.
[0190] • The second, between device_B and device_A, is encrypted by the SSH session (110).
[0191] • The third (117), between the proxy-firewall server and socket_A of the platform, is protected by a broad security context configured by the proxy-firewall server through the Netfilter (107) of device_A.
[0193] When the IoT platform requires to initiate a communication with socket_B (118) of the process of device_B then it uses one of the reverse socket-proxies (115) generated in device_A; the one corresponding to the alias of socket_B and the id_B of device_B (id_DispSocket) that the IoT platform intends to access. This communication also consists of three parts: the first (119), between the IoT platform and the reverse proxy socket, is protected by a strict security context configured by Netfilter on device_A. The second, between device_B and device_A is protected by the secure session (110) and finally the third (120), between the agent and socket_B (118) of process_B of device_B is protected by another strict security context of the device_B.
[0195] The management of all established sessions, assigned socket-proxies and access permissions to them for users of the operating system of device_A, are handled by the connection-broker (121) and its database (122) at the behest of the proxy server -firewall.
[0197] Access to sockets_B on device_B or protected sockets on device_A is facilitated by priority dialing rules that define the respective strict security contexts. The marking rules in this example apply including the con_Id in the TOS field of the IP protocol. Marking traffic following this strategy facilitates Netfilter operation and proxy-firewall implementation, but limits to 255 different security contexts applicable to each protected socket. This figure, in the case of reverse socket-proxies, is sufficient because IoT devices are usually resource-limited devices that are not usually prepared to allow multiple simultaneous connections: the information and services offered are presented to the user final or final application through own resources of the platform to which they connect.
[0199] Sockets_A are also protected sockets and also require access permissions for the accounts of each device_B with processes that require connecting. The number of strict security contexts necessary in this case for each socket_A would be as large as the number of devices_B that require communication with said socket, and in most IoT projects they do exceed 255. Therefore, in this case, apply a single broad security context to an entire group of users on device_A, so that the user accounts on device_A that each device_B uses when connecting, share permission_A ^G ; for which these user accounts are included in the same group with said permission.
[0201] Example 1: Establishing a direct proxy of a socket A on a device B and a reverse proxification of a socket B on a device A
[0203] In figure 2, a sequence diagram is described in which, in an embodiment of the invention, device_B requires to proxify two ports: a socket_A directly and a socket_B in a reverse way. In this example a device_B intervenes with an agent_B (201) and a device_A with a proxy-firewall server (202), a connection-broker (203) and a database (204). This example is generalizable to establish any number of direct and / or reverse proxies in the same session without the need to do it repeatedly.
[0205] First, agent_B starts session (205) on the proxy-firewall server using the settings defined in a profile_B ^A. During the authentication process (206), the proxy-firewall server determines what type and number of proxifications are those that the agent_B can perform from the profile_B ^A used in the session establishment. Once the authentication is performed and the session is established, the proxy-firewall server forks itself (207) in the account user_A ^B. In this way, a new instance of the proxy-firewall server is generated as fork (208) in that account, which allows a separation of privileges.
[0206] This fork requests (209) the connection-broker to reserve a free socket to establish the reverse socket-proxy for socket_B. Likewise, said request also contains a request for resolution of socket_A to obtain the protected socket assigned to said socket_A. The connection-broker queries (210) in the database if permission_A ^G exists for socket_A and inserts or updates the socket_ record for socket_B according to profile_B ^A. If this socket_record previously existed, it is checked if there is also any valid access_record relative to that socket_record. If it exists, the socket value assigned in the socket_register is kept. If it does not exist, the socket value for socket_register is updated with a new one that is local; always and in any case belonging to the pool of addresses reserved for this method and that the socket is available. In the event that the socket_register does not exist or in the case of having to generate a complete access_register, the socket is randomly chosen from those that are free in the pool of reserved addresses.
[0208] Once these actions are finished, we proceed with the answer (211). This response includes the resolution of socket_proxy (the socket value assigned in socket_register for socket_B) and the resolution of socket_A (the value assigned in socket_register relative to socket_A) in the form of socket_registers. After this, the fork of it (212) is notified and this in turn does the same with agent_B (213). The latter issues a request (214) to the fork to initiate a listening protected socket that corresponds to the previously assigned reverse proxy socket (215). Likewise, agent_B starts listening to a protected local socket of device_B that corresponds to the direct proxy-socket (216).
[0210] Example 2: Request for a resource from a protected socket of device A by a process A
[0211] An example of a procedure is described below by which access to a protected socket of device_A is granted to the user of process_A so that it can communicate with said protected socket. This procedure is illustrated with a sequence diagram depicted in Figure 3. The access_register and security context are applied to the local user account of device_A relative to user_A. Protected sockets can never be directly accessible from remote machines and their access is always local and by users within the security context. This is made possible by the separation of privileges of POSIX systems that allows you to configure security contexts.
[0212] In order to access the protected socket (301), the account user_A in which process_A (302) that requires access is executed, must have the user permission to do so in the database (303) of the connection-broker (304 ). Process_A makes a request (305) to the proxy-firewall server (306) to proceed with the resolution of the protected socket based on the socket alias and its id_DispSocket and thus know to which local socket to direct the resource request. Said request (305) occurs in this example through a system call. The origin of this call does not require the handling of user_A credentials before the proxy-firewall server in the request itself since it takes advantage of the separation of privileges of the POSIX-type system through which the proxy-firewall server can uniquely identify the account of origin of said call.
[0214] This request is validated (307) by the connection-broker, which initially makes a query (308) in the database to verify with its response (309) if user_A has permission. If the permission is of the permission_A ^G type, the granting of an access is not required and the response (310) is proceeded to the proxy-firewall server indicating that access is available and which socket is protected. However, if the permission is of type permission_A ^U , the connection-broker must first grant access for user_A to the protected socket. To do this, the connection-broker generates an access_record (311) and registers it in the database (312). Once the confirmation (313) is received from the database that the record was saved correctly and that there was no previous one, the proxy-firewall server is informed (314) of the need to configure the strict security context for user_A .
[0216] The proxy-firewall server uses the information in the access_log to define the required dialing rule that grants user_A communications access to the protected socket. These dialing rules are inserted (315) into the operating system through the network framework (316). If there is a valid previous record, it is not necessary to generate another access_record for user_A because user_A already has access. After receiving confirmation (317) of the insertion of the rules (if necessary), the proxy-firewall server initiates an access monitor (318) to periodically update the status of the last_activity variable of the access_register. In this example, monitoring is done at 5 minute intervals. This access monitor, like the dialing rules and that the access_register is only carried out if there was no other valid previous access_register.
[0218] Once it is confirmed that user_A has access to the protected socket, the proxy-firewall server notifies (319) process_A which is the protected socket that it needs to access so that it can send the resource's request (320) to the protected socket and receive its response (321).
[0220] Example 3: Access to a reverse socket-proxy by a remote process through a local proxy of device A that translates requests from the application protocol https to http requests transparently
[0222] Figure 4 shows an example of an embodiment of device_A that allows access (401) (402) (403) to the socket-proxies (404) in device_A (405) from a process in a device other than device_A through of proxified connections (406) in sessions (407) established with remote devices. The first case (401) is an example of this type of communication in which applications that use HTTPS access resources from socket_B, but without requiring that the socket_B process of this device_B has to have support for HTTPS or an authentication scheme . This access is done through a reverse proxy-socket on device_A from a socket_B of device_B that has an established session with device_A.
[0224] The communication as such between the application and the process of device_B is transparent and is carried out through an intermediate proxy (410) that also converts communications that use HTTPS into HTTP communications. First, the end application requests a resource from device_B offered by a socket_B proxied on device_A and directs this request (401) to the intermediate proxy. This software, which converts the request (501) from HTTPS to HTTP, can be implemented in a multitude of programming languages on the server side (411); such as PHP, Node.js, Go, Python, etc. To enable access to the corresponding proxy socket, the proxy receives the information of the communication destination through subdomains (502) and also receives the credentials that the end application uses to gain access to the proxy socket; the latter included in the request headers.
[0226] The web server (412) must be configured to redirect all requests on all possible subdomains of the proxy to the main URL of the intermediate proxy, including the subdomains as parameters. From the headers, the intermediate proxy obtains the credentials that the final application attaches and that allow the intermediate proxy to validate the request and request access to the socket_proxy. The credentials are protected by HTTPS as they are in the headers. The request received by the intermediate proxy has the following elements: • The id_DispSocket, which in this case corresponds to the id_B (503) of the socket_B to which the reverse socket-proxy leads, and which allows it to be identified together with the alias.
[0227] • The alias (504) of socket_B that allows identifying the socket-proxy together with the id_DispSocket.
[0228] • The domain (505) of the proxy.
[0229] • The resource (506) that is requested from socket_B.
[0231] Protection of communications on any of the required dynamic subdomains is possible with a single wildcard SSL certificate based on X.509 certificates that enables HTTPS protection for the main proxy domain and all possible subdomains. On the other hand, end-to-end communication is also transparent and independent of other communications that the final application may have with other socket-proxies, as each one needs a different subdomain.
[0233] The credentials that go in the headers are used by the intermediate proxy to validate the access to the socket-proxy for the user account in which the intermediate proxy runs according to the permissions in the database (414) for that account of user. This access can be requested directly from the connection-broker (415) through the proxy-firewall server (416) or require prior validation of the platform.
[0235] Once the conversion from HTTPS to HTTP has been carried out and access to the proxy-socket has been enabled for the user account that runs the intermediate proxy, it suppresses the headers with the credentials to make the authentication process transparent and sends the HTTP web request ( 417) towards the corresponding socket-proxy. This request, when passing from the user space (418) to the kernel space (419) is marked by the network framework (420) if the access was granted correctly and the corresponding marking rule was inserted. Subsequently, this request is routed and directed (421) towards the proxy socket and will be processed or discarded according to the filtering rules, being able to only enter the user space again if it has a valid markup.
[0237] Both the dialing and filtering rules are introduced into the network framework of the operating system at the initiative of the proxy-firewall server, following the instructions described in examples 1 and 2. Finally, the request is received by the proxy socket-proxy. stand-alone (422) and transmitted as proxied communication to device_B.
[0238] Example 4: Access to a socket-proxy by a remote process through an intermediate proxy of device A in which the proxy converts incoming requests from the secure version of an application protocol to the insecure version of the same:
[0240] In this example, the previous example is generalized. Following the same scheme, example 3 can be applied to other application-level protocols used by device_B programs that require security but do not implement it. Some examples of these protocols can be HTTP / 2, MQTT, and COAP. All of them also have a secure version of themselves, and with a proxy that transparently converts secure requests to insecure requests, it is feasible for devices_B to use the insecure version of the protocol together with the system exposed in the present invention to achieve secure communication. end to end.
[0242] Example 5: Access to socket-proxies by a platform that collects information from them, processes it, stores it and then offers it to the final applications in the form of its own resources
[0243] Communication (424) represents a very common mode of operation in IoT ecosystems. In this case, the final application does not require "direct access" to the resources of the proxified sockets, but to the information and services that the platform produces from those resources that it obtains autonomously. The platform, for this, does establish periodic communications with the protected sockets to which it has permission to access and from which it collects information with which it then develops its own resources and services, which it could continue to offer even when all sessions (407) were temporarily down. The operation of the system proposed by the present invention in this case is analogous to that of example 2. In particular, process_A (302) is the one that executes the platform to communicate with the local socket it requires at all times. The platform must have to This of a user account of device_A with permissions_A ^U sufficient to be able to access all the socket-proxies relative to the devices configured in the p the platform and from which it obtains the resources periodically. On the other hand, the platform can also offer necessary information to other devices through protected sockets of type socket_A (425).
[0245] Example 6: Requesting access to protected sockets of an AF device through direct proxifications and at the behest of a process A
[0247] This example illustrates how device_A, at the request of process_A (601), requests through the proxy-firewall server (602) and agent_A (603) a direct proxification (604), (426) of some protected sockets of a device_AF ( 605). This allows process_A to securely access protected socket resources on that remote device. To do this, process_A requests (606) from the proxy-firewall server a resolution of remote sockets, supplying the alias, the id_DispSocket and the id_DispProxy of each protected socket to be accessed. In this case, the id_DispSocket is different from the id_DispProxy and for that reason, the proxy-firewall server determines that these proxies are required to be directly proxied from other AF_devices. In the example, all the sockets to be proxied come from the same device, but it does not necessarily have to be this way in other cases.
[0249] The direct proxification request made by process_A to the proxy-firewall server is made by means of a system call that instantiates the proxy-firewall server as a process in that user environment. To proceed with direct proxification, the proxy-firewall server initially requests (607) the connection-broker (608) to reserve and register (609) in the database (610), some free local sockets that belong to the address pool protected to map direct socket-proxies. Reserving these sockets also involves the insertion of a socket-type registro_socket proxy, and each reserved access_log socket if available permisos_A ^U for each.
[0251] Once the reservation (611) of these local sockets is confirmed, the proxy-firewall server receives the reserved sockets in the response (612) from the connection-broker and requests (613) from agent_A the establishment (614) of a session with the device_AF to resolve protected sockets that need to be proxied. The agent_A will use a profile_UA ^AF relative to user_A that authenticates in the account user_A ^AF of device_AF and that is supplied by the proxy-firewall server.
[0253] Once the session is established using said credentials, the AF_device performs the pertinent actions (615) described in Example 7 to process the received proxy request. When device_AF responds (616) to agent_A with the protected sockets resolved, agent_A notifies (617) the proxy-firewall server and proceeds to establish direct proxifications (604).
[0255] Although the direct socket-proxies are already established, access to them is not possible as they are protected sockets. In order to grant access to user_A of process_A it is necessary to apply the respective permissions_A ^U of the database. These permissions are translated by the proxy-firewall server into dialing rules that are inserted (618) through the network framework. Once this entry is confirmed (619), the proxy-firewall server responds (620) the request of process_A with the direct proxy sockets resolved so that can connect to them. In parallel, the proxy-firewall server instantiates an access monitor (621) that keeps accesses active while process_A is running.
[0257] Example 7: Communication example in which an AF device accesses some protected sockets of a device A by direct proxification
[0259] This example is linked to the previous one: in example 6, a device_A was connected to a device_AF to require direct proxifications and this example illustrates what happens on that device_AF. However, for descriptive consistency, in the present example that device_AF will be referred to as device_A and the device that connects to device_A will be referred to as device_AF. Once this detail is clarified, we proceed to explain how in this example the direct proxification of protected sockets is granted to an AF_device.
[0261] The first part of the process is similar to that described in Example 1, except that the device initiating the session this time is a device_AF (instead of device_B) and that the request consists only of direct proxifications. To do this, Device_AF has an agent_AF and a connection profile to connect to device_A that allows it to establish a session in which the resolution of the protected sockets required by device_AF is requested. Said device_AF uses its credentials from profile_UA ^AF to connect to user_A ^AF's account in the operating system of device_A. This account must have permission to access the protected sockets to be proxied. Once the credentials have been authenticated by the proxy-firewall server of device_A, this software is instantiated with a fork of itself under the account of user_A ^AF .
[0263] Once this point is reached, the proxy-firewall server fork must evaluate if user_A ^AF of device_A has the necessary permissions to access the protected sockets required by agent_AF. In device_A, the procedure for checking, marking and assigning each access_register is the same as that described in example 2 and comprising the sequence diagram of figure 3 from (307) to (319). Once the permissions have been confirmed and, where appropriate, the accesses to the required socket-proxies have been granted and the relevant dialing rules have been defined and inserted, the resolved socks are returned to the agent_AF so that it can proceed with the start of direct proxification. To ensure that user account_A ^AF of device_A has access constantly for the duration of the session, an access monitor is instantiated that periodically updates all accesses to the sockets-proxy even if there has been no traffic. This will be done for the duration of the session between device_AF and device_A.
[0265] Example 8: Establishing a Proxification of Protected Sockets from Device A to Device AF Reversely at Process A Instances from Device A
[0266] There is the possibility that a platform of a device_AF requires access to proxified resources of devices_B with which it does not maintain a session, or that those devices_B require resources of a foreign device_A with which it does not maintain a session. In this case, device_A that maintains a session with devices_B, takes the initiative and initiates a process of reverse proxification of local protected ports towards device_AF; either by instances of some process or by some type of network configuration established that indicates it. With reverse proxification, device_A makes the protected sockets it proxies available to device_AF. To do this, agent_A establishes a communication session with device_AF using an UA_profile ^AF supplied by the proxy-firewall server at the request of a process_A.
[0268] In this example, process_A requests reverse proxification from the proxy-firewall server of device_A. As in example 2, it is essential that the proxy-firewall server of device_A makes sure that user_A that executes process_A has the necessary permissions to be able to access the protected sockets that it requests to be proxied and that, where appropriate, it grants and record the pertinent accesses and elaborate and insert the appropriate dialing rules. The procedure is identical to that described in example 2 in the sequence diagram from (307) to (319). The proxy-firewall server is also required to install an access monitor that verifies that the accesses remain open while process_A is running, periodically updating the status of each access_register to prevent them from being automatically closed due to inactivity. After this, the proxy-firewall server communicates the resolved protected sockets to process_A so that any process of user_A ^AF of device_AF can access the protected sockets of device_A through the established reverse proxy-socket. To do this, the proxy-firewall server has been instantiated from user_A account, and therefore it can launch agent_A using the UA ^AF profile that starts the reverse proxification procedure of the protected sockets already accessible.
[0269] Example 9: Proxying protected sockets from an AF device to a device A in reverse at the behest of the AF agent of the AF device:
[0271] This example 9 is closely related to the previous example, 8. In this example, a device_A at the request of a process_A initiates the establishment of reverse proxifications towards a device_AF. In the present example, what happens in that device_AF is shown, in which again, and in order to preserve descriptive coherence, that device_AF will be referred to as device_A and vice versa.
[0273] Consequently, the proxy-firewall server of device_A receives a session establishment request from device_AF that uses a profile_UA ^AF by which it is requested to perform a reverse proxification of certain protected sockets from device_AF to device_A. This request forces the proxy-firewall server to be instantiated as fork_A ^AF in the user account_A ^AF of device_A whose credentials were used by the agent_AF of device_AF to connect on device_A. Fork_A ^AF requires requesting the connection-broker to reserve local protected sockets on device_A in order to perform reverse proxification.
[0275] This procedure is similar to the one followed in example 1 by device_A in that device_A must reserve local sockets for the reverse proxifications requested by device_B. The main difference is that these protected local sockets resulting from the proxification are new and there are no relative permissions in the database that give access to them in any way. For this reason, the connection-broker, in addition to reserving those sockets, must insert socket_registers and permissions_A ^ü for each reverse proxy-socket that enable user_A ^AF of device_A to access each socket resulting from the proxification in a similar way as is done in Example 6 (607), (609), (611) and (612). This reservation, however, is made only for reverse socket-proxies.
[0277] Once the sockets have been reserved and the corresponding permissions inserted, the relevant dialing rules must be generated and inserted into the system so that user_A ^AF has access to those protected sockets. The proxy-firewall server instantiates an access monitor to ensure that the access_logs related to each proxification maintain a low idle time that prevents their automatic shutdown while process_A is still running. The proxy-firewall server, being instantiated from the account of user_A ^AF , is part of the security context configured when inserting the dialing rules and, therefore, this instance has access to the protected sockets reserved in this example for the reverse proxification. Once these actions are finished, the proxy-firewall server proceeds with the reverse proxification requested by the agent_AF using the sockets reserved for it.
[0279] Example 10: Remote update of software elements:
[0281] One of the main advantages of the present invention is the decoupling of the security functionalities of the applications of the devices_B and its corresponding simplification in its design and maintenance. In devices_A, the processes that make use of the system proposed by the invention do not require security frameworks either, but they must incorporate the method described in this document in their programming in order to communicate with the protected sockets. However, the communication interface is based on system calls and packet marking, so it is independent of security protocols and, consequently, it is feasible to update in device_A the system described in the present invention also without affecting device applications_A.
[0283] In devices_A and devices_B similar to those proposed in the preferred embodiment of the invention, it is possible to update the agent of device_B from device_A without affecting the rest of the software. For this, it is necessary for device_B to have a simplified version of the proxy-firewall that has a stand-alone proxy server and a suitable configuration in profile_B ^A that allows device_A to use a reverse proxy-socket to update the agent for device_B . This strategy can be generalized to provide update services to other software elements outside the system described by the invention.
[0285] In the particular case of updating the stand-alone proxy client, the process includes:
[0286] • Request, through the communication session established between agent_B and the proxy-firewall server, the initiation of a procedure for updating the stand-alone proxy client of agent_B at the initiative of the proxy-firewall server.
[0287] • Receive, from agent_B, the new version of the proxy client and update profile_B ^A.
[0288] • Test, by agent_B, the new version of the proxy client with the updated profile_B ^A establishing a new communications session.
[0289] • If this new session is successfully established, remove the previous version of the proxy client and replace it with the new version.

权利要求:
Claims (15)
[1]
1. A secure communication method by network socket proxification comprising:
• establish a secure communications session (110) that allows sockets proxifications between two devices called “device_A” (106) and “device_B” (101), where the first uses a proxy-firewall server (111) to host and the second uses an agent of the proxy-firewall server called "agent_B" (109) that initiates the establishment of said session, using a stand-alone proxy client (112) that implements a secure communication protocol using configuration data and credentials of a user account called "user_A ^B " defined by a configuration profile of device_B called "profile_B ^A " that allow you to connect to the account of user_A of device_A;
• establish some proxifications called "direct proxifications" (114) if these are produced from the application sockets that are listening on device_A, such as those called "socket_A" (123), and as described in profile_B ^A ;
• establish proxifications called "reverse proxifications" (115) if these occur from the sockets of the applications that are listening on device_B called "socket_B" (118) and as described in profile_B ^A ;
• protect instances of the proxy-firewall server of device_A communications from sockets_A and reverse proxifications on device_A by configuring security contexts configured with dialing rules and filtering network packets of these local communications, using as a delimiter parameter from the context the user of the operating system process of device_A origin of each local communication; and
• protect the communications of sockets_B and direct proxifications on device_B to instances of the agent of device_B through the configuration of security contexts configured with rules for marking and filtering network packets of these local communications, using such contexts as a delimiting parameter the user of the operating system process of the source device_B of each local communication.
[2]
2. The method according to claim 1, where security contexts are established for direct and reverse proxifications, further comprising:
register the reverse proxifications in a database (122) of a connection-broker (121) of device_A as a register called “register_socket” where the relative information of each reverse proxification is stored, comprising:
or a variable called "id_DispSocket" that stores the device id with the socket to be proxified, and which according to this claim would correspond to the id of device_B called "id_B";
or a variable called "id_DispProxy", which identifies the device with which it maintains the session that enables the protected socket to which this socket_register refers, and which according to this claim would correspond to the id_B;
or a variable called "aliases", which in this claim would store the alias of the socket to be proxified from the id_DispSocket;
or a variable called "socket" that according to this claim would keep the free local socket, reserved by the operating system of device_A for proxification and that has a network address value belonging to a pool of local network addresses of device_A reserved for this method; and
or a variable called "socket_type" that determines the socket class to which this record refers, and which according to this claim would be "socket_B"; the entry, during the startup sequence of the operating system of device_A, of a general rule of packet marking through its network framework (107) by the proxy-firewall server that determines to eliminate any possible marking of network packets in any communication, produced between local sockets of device_A, with local addresses belonging to the pool of local addresses reserved for this method;
the introduction, during the startup sequence of the operating system of device_A, of a general rule of packet filtering by the proxy-firewall server that determines to discard any packet with origin and destination a local socket of device_A that lacks a mark, always and when any of the sockets uses a local network address belonging to the pool of local addresses reserved for this method;
the entry, during the startup sequence of the operating system (102) of device_B and through the latter's network framework, of a general filter rule for each socket_B and direct proxification on device_B that determines the discard of incoming packets with that destination and originating a non-local network address;
the entry, during the startup sequence of the operating system of device_A and through a network framework (107) of the latter, of a general rule of packet filtering by the proxy-firewall server that determines to discard any packet with source or destination a local address from the pool of local addresses reserved for this method that has a non-local address as source or destination;
the entry, if it does not exist, during the startup sequence of the operating system of device_A, of a record_socket in the database of device_A relative to each socket_A of device_A collected in the configuration profile called "profile_A", each record_socket containing information that understands:
or the id_DispSocket, which in this claim would be equal to the id of device_A called "id_A";
or the id_DispProxy, which in this claim would also be equal to the id_A;
or the alias, which in this claim would be the same as the one used by socket_A to be registered; or the socket, which in this claim would be equal to is equal to the local socket used by process_A for socket_A defined in profile_A; and
or the type_socket, which in this claim would be equal to "socket_A";
the entry, if it does not exist, during the startup sequence of the operating system of device_A, of at least one record called "access_record_A" in the database of device_A relative to each socket_A of device_A collected in profile_A, each access_record_A containing information that understands:
or a variable called "con_Id" that stores the identifier of the access with the same name,
or a variable named "socket" that stores socket_A, and
or a variable named "group_id" that stores the group id of the operating system user of device_A corresponding to user_A of process_A originating the communication request to which access has been granted;
the entry, during the startup sequence of the operating system of device_A, through the connection-broker (121), at the request of the proxy-firewall server and according to the configuration set in profile_A, of some permissions_A ^G in the database ( 122) comprising:
or the id_Group, which stores the id of the group of users of the operating system of device_A to which access permission is granted;
or the alias, which stores the alias of socket_A;
or the socket, which stores the value of socket_A;
the entry, during the startup sequence of the operating system of device_A, through the network framework (107) and at the instances of the proxy-firewall server, of some priority dialing rules over the general ones and that are relative to the permissions_A ^G registered in this claim for each socket_A to grant access permanently to the user groups of device_A relative to the previous permissions as defined in profile_A; and
• the deletion, during the startup sequence of the device_A operating system, of each access_register, of their respective permissions from the database relative to the socket_registers whose socket_type is “socket-proxy” and the deletion of the socket_register itself.
[3]
3. The method according to the preceding claims, where a secure communication is established between network sockets, in which a network resource that is offered by socket_B of a process called "process_B" (118) of device_B is requested by a process called "process_A" (302) of a user called "user_A" of the operating system of device_A and whose resource is accessible through a reverse proxy socket (301), it also includes:
• request (305) by process_A to the proxy-firewall server through a system call the resolution of the protected socket based on the id_B and the alias of socket_B to obtain the local reverse proxy socket through which it can access socket_B;
• request (307) the connection-broker from the proxy-firewall server to verify the existence of an access permission of user_A called “permission_Au 'that enables it to access the required reverse proxy socket, the socket resolution request- reverse proxy and granting an access to the reverse proxy socket named "access_log";
• check (308) by the connection-broker in the database the existence of the permission_A ^U and perform the resolution of the reverse socket-proxy;
• generate (311) the access_record, if it does not already exist in the database, in which a communication access identifier is assigned by the connection-broker to the reverse socket-proxy called “con_Id” relative to user_A and the socket protected; • save (312), or update if necessary, in the database by connection-broker the generated access_ record, which includes:
or the relative con_Id of the access granted,
o the socket to which access is granted and which consists of the local network address and the port,
or a variable called "user_id" that stores the id of the operating system user of device_A corresponding to user_A of process_A originating the communication request to which access has been granted; and
or a variable called "last_activity" that saves the moment in which access has been granted, which will be updated by an access monitor reflecting its activity status;
• enable (315) a specific priority rule over the general rules for marking packets for the operating system of device_A by the proxy-firewall server, which determines that all local communication packets between user_A executing process_A and the socket -reverse proxy, include the identifier of the access assigned with_Id defined in the access_register corresponding to the reverse proxy-socket and user_A;
• instantiate (318) by the proxy-firewall server an access monitor that verifies if there is access traffic to the reverse proxy socket periodically and updates the value of last_activity; and
• proceed with the communication (320) between process_A and socket_B that offers the resource through the reverse proxy socket existing in device_A;
[4]
4. The method according to the preceding claims, where process_A of user_A on device_A requests the proxification directly on device_A of several protected sockets of a foreign device_A called “device_AF”, it also comprises: • requesting (606) by the process_A to the proxy-firewall server a resolution of the direct proxifications to be made, requiring a response with the assigned local sockets;
• request (607) to the connection-broker by the proxy-firewall server a reservation of local sockets without using them to use them as direct socket-proxies, once the protected sockets of the AF_device that are required to be proxied directly by means of the agent_A;
• register (609) in the database, by the connection-broker, the pertinent permissions_A ^U and access_registers that allow the user_A to access the direct socket-proxies;
• register (609) in the database each socket_register generated by each socket reservation to be proxied directly, and which includes:
or the id_DispSocket, which in this claim would store the id of the corresponding protected socket device and which knows process_A;
or the id_DispProxy, which in this claim would store the id of the device_AF called "id_AF";
or the alias, which in this claim would save the alias of the socket that process_A wishes to proxify and that process_A also knows;
or the socket, which in this claim would keep the free local socket that is assigned to perform each direct proxification and which has a network address value belonging to the pool of local network addresses of device_A reserved for this method; and
or the type_socket, which in this claim would be equal to ‘socket_proxy’;
• request (613) agent_A to establish a communications session with device_AF using some credentials to access the device_AF of user_A provided by the proxy-firewall server, session through which the resolution of the protected sockets of device_AF is performed to prox directly on device_A;
• request (614) to the device_AF through the session established in this claim the resolution and establishment of the accesses for the protected sockets required of the device_AF indicated in the request;
• establish (618) by the proxy-firewall server the relevant dialing rule for each permission_A ^U by means of the network framework that allow the user_A to access the direct socket-proxies;
• request the establishment of each direct proxification (604) in device_A towards each corresponding protected socket of device_AF as required by process_A;
• respond (620) to process_A by the proxy-firewall server with the requested socket resolution; and
• instantiate, by the proxy-firewall server, an access monitor (621) that periodically updates the last_activity value of each access_register inserted in the database in this claim.
[5]
5. The method according to the preceding claims, where several protected sockets of device_A are in turn proxied directly to a device_AF by an agent of device_AF called "agent_AF" using configuration data and credentials of a user account called "user_A ^AF ”defined by a configuration profile of device_A called“ profile_UA ^AF ”that allow said agent_AF to connect to the account of user_A ^AF of device_A, also comprising:
• establish a secure session between agent_AF and the proxy-firewall server of device_A at the initiative of agent_AF;
• request in the establishment of said session a resolution of each protected socket of device_A that is required by agent_AF;
• instantiate a fork of the proxy-firewall server in the account user_A ^AF called “fork_A ^AF ”;
• request from the connection-broker by fork_A ^AF a resolution of the protected sockets based on the alias and id_A of each socket_A, and the alias and id_B of each socket_B indicated by agent_AF;
• verify by the connection-broker of device_A the existence of sufficient permissions for user_A ^AF in the database to be able to access the protected sockets;
• request from the connection-broker by fork_A ^AF a communication access for each protected socket for the account of user_A ^AF of the operating system of device_A for all those protected sockets required by the agent_AF with which user_A ^AF does not yet have access ;
• record each access_record of each granted access in the connection-broker database;
• Establish by fork_A ^AF the marking rule relative to each access_record by means of the network framework of the operating system of device_A that allow user_AF to access each protected socket;
• respond to agent_AF with the value of each protected socket required so that later, agent_AF can perform direct proxifications; and
• instantiate an access monitor by fork_A ^AF to periodically update the last_activity value of each access_ record inserted in the database in this claim.
[6]
6. The method according to claims 1-3, where several protected sockets of device_A are proxied in a reverse way in device_AF upon request of process_A of user_A of device_A through agent_A, it also comprises:
• request by process_A the proxy-firewall server to perform a reverse proxification of some protected local sockets to which it has access;
• request the connection-broker to resolve the local sockets required in the proxification requested by process_A;
• check, by the connection-broker, if user_A has the necessary permissions to access the protected local sockets required in the proxification request;
• insert into the database, by the connection-broker, communication accesses to the protected sockets for the account of user_A by all those protected sockets with which it does not yet have access;
• record communication accesses in the connection-broker database as access_log;
• establish, by the proxy-firewall server, the dialing rule pertinent to each access_record inserted in the database in this claim that allows the user_A to access all the source sockets of the reverse proxies;
• request agent_A, by the proxy-firewall server, to establish a communications session with device_AF using access credentials to device_AF of process_A provided by the proxy-firewall server;
• request, by agent_A at the establishment of said session, a reservation of a protected socket of device_AF for each socket to be proxied in a reverse way towards that device;
• instantiate, by the proxy-firewall server, an access monitor to periodically update the last_activity value of all the user_A access_registers required in this method; and
• send to device_AF by agent_A the request to establish reverse proxifications.
[7]
7. The method according to claims 1-3 and 6 where several protected sockets of device_AF are proxified in a reverse way on device_A by action of agent_AF using configuration data and credentials of an account "user_A ^AF " defined by an "profile_UA ^AF ”That allow you to connect to the account of user_A ^AF of device_A, it also includes:
• establish a secure session between agent_AF and the proxy-firewall server of device_A at the initiative of agent_AF;
• request in the establishment of said session the reservation of protected local sockets of device_A to carry out a reverse proxification in device_A of sockets of device_AF;
• instantiate a fork_A ^AF of the proxy-firewall server in the user account_A ^AF ;
• request from the connection-broker, by fork_A ^AF , a reservation of unused local sockets to use them as the reverse socket-proxies indicated in the received request;
• register in the database, by the connection-broker, the socket_registers and access_registers relative to the sockets reserved for each reverse proxification; • add, by the connection-broker, a permission_A ^u to the database for each socket reserved for user_A ^AF ;
• insert into the system, by fork_A ^AF , a marking rule for each permission_A ^U through the network framework;
• instantiate, by fork_A ^AF , an access monitor to keep active accesses related to reverse proxification; and
• establish reverse proxifications, by fork_A ^AF , using reserved sockets.
[8]
8. The method according to claims 3-7, further comprises updating the last_activity variable at the request of the access monitor in each access_register involved in the method in different scenarios:
• if the access_log is created according to claim 3, the variable last_activity of the access_log will be updated to instances of the access monitor instantiated by the proxy-firewall server whenever there is traffic from the account of user_A towards the proxy-socket; and
• if the access_register is created according to claim 4,5,6 or 7, the last_activity variable of each access_register will be updated to instances of the access monitor instantiated by the proxy-firewall server as long as the process that requested the proxification is kept running which caused the creation of each access_ record in the database.
[9]
9. The method of claims 1-3, where a process called "process_C" of a device called "device_C" issues a secure request for the resource offered by socket_B of device_B to a proxy executed by user_A, further comprising:
• The use of network subdomains of the proxy's main domain as parameters of the request that the proxy requires in order to request the resolution of the protected socket through the connection-broker;
• an X.509 wildcard certificate properly configured to provide security for proxy subdomains;
• receive the credentials of process_C in the request headers that allow the proxy to verify the identity of process_C and check if it has the permission_A ^U required to process the request;
• establish secure communication between process_C and the proxy using a secure communication protocol known to process_C and the proxy;
• delete the request headers; and
• establish a communication between the proxy and the protected socket that communicates with socket_B according to claim 3.
[10]
The method according to claims 3-9, where the communication access relative to the access_register is closed when inactivity exceeds a threshold called "um braljnactivity" in profile_A, further comprising:
• removal of the dialing rule from device_A operating system relative to access_log;
• removal of the access_log from the connection-broker database of device_A; and
• elimination of the permission_A ^U relative to the access_register in case it is relative to a direct proxy socket.
[11]
11. The method according to claim 3, where it is required to update the security in communications between the stand-alone proxy client and the stand-alone proxy server, further comprising:
• request, through the communication session established between agent_B and the proxy-firewall server, the initiation of a procedure for updating the proxy client of agent_B at the initiative of the proxy-firewall server;
• receive, from agent_B, the new version of the proxy client and update profile_B ^A ;
• test, by agent_B, the new version of the proxy client with the updated profile_B ^A establishing a new communication session; and
• If this new session is successfully established, remove the previous version of the proxy client and replace it with the new version.
[12]
12. A system for securely communicating network sockets comprising:
• a software module called “proxy-firewall server” housed in a device called “device_A” and that is configured to:
or receive session establishment requests from other devices through a secure protocol through a stand-alone proxy server,
o configure strict and comprehensive security contexts through system calls to the network framework of the device operating system_A,
o process proxy or socket-proxy requests through established sessions or system calls from local processes,
o monitor access to local sockets through access monitors, or manage security updates of the devices with which it maintains a connection, and
or establish, through system calls to the network framework, the protection of the local sockets used in the proxifications on device_A;
a type of configuration profile of the proxy-firewall server to define the aspects related to the operation of the proxy-firewall server and the connection-broker called "profile_A";
a software module, which functions as an agent for the proxy-firewall server, configured to:
or initiate session establishment requests towards the proxy-firewall server through a software module called "stand-alone proxy client" that implements a secure protocol,
o make direct and reverse socket proxification requests, and o establish local socket protection;
being this software named as:
or agent_A, if it is on device_A;
or agent_AF, if it is in a foreign device_A called device_AF itself;
or agent_B, if it is on a device named “device_B”;
a type of agent configuration profile named:
o profile_B ^A , if the profile is to configure the session that the agent of device_B performs on device_A or
or profile_UA ^AF , if the profile is to configure the session that the agent of device_A performs with device_AF at the request of user_A;
a software module called "access monitor" used to keep a record and control over the proxifications made and the accesses to them on device_A;
a type of record of device_A called "record_socket" relative to a protected socket and which comprises:
or a variable called "socket" that stores the protected socket referred to in this socket_register and which can be of three types:
- socket_B, if the socket to register is a socket-proxy that offers a resource of a device_B;
- socket_A, if the socket to be registered offers a resource from a process of device_A itself and is not the result of any type of proxification;
- socket-proxy;
or a variable named "alias" that stores the alias of the protected socket, which can be of two types:
- the alias of a socket_B named "alias_B", and
- the alias of a socket_A named "alias_A";
or a variable called "id_DispSocket" that stores the id of the device that has the protected local socket and that can be of three types:
- the id of a device_B named "id_B" if the socket_register is of type socket_B,
- the id of a device_AF named "id_AF" if the socket_register is of type socket-proxy, and
- the id of a device_A named "id_A" if the socket_register is of type socket_A;
or a variable named "id_DispProxy" that identifies the id of the device to which the protected socket leads; and
or a variable named "socket_type" that determines the type of protected socket referred to in this record, which can be found between: socket_A, socket_B and socket-proxy.
a type of record called "access_record" of a user of the operating system of device_A generated by each access granted to a protected socket of the direct or reverse socketproxy type, which comprises:
or a variable named "c o n jd" that stores the identifier of the communication access to the proxy-socket of a user_A,
or a variable called "socket" that stores the protected socket to which access is granted, which is made up of the local network address and the port, or a variable called "user_id" that stores the identifier of user_A of process_A originating the request communication to which access has been granted, and
or a variable called "last_activity" that saves the moment in which access has been granted and that will be updated by an access monitor reflecting its activity status;
a type of record called "record_access_A" of a group of users of the operating system of device_A generated by each access granted to a protected socket of type socket_A, which comprises:
or a variable called "con_Id" that stores the identifier of the access with the same name,
or a variable named "socket" that stores socket_A, and
or a variable named "group_id" that stores the group id of the operating system user of device_A corresponding to user_A of process_A originating the communication request to which access has been granted;
a type of record to define the access permission called "permission_Au", which defines a strict security context by granting user_A of device_A the possibility of accessing a protected socket of the direct or reverse socket-proxy type, which comprises:
or a variable called "user_id" that stores the id of user_A of the operating system of device_A,
or a variable named "alias" that stores the alias of the protected socket of another device that is proxied as socket-proxy on device_A, and
or a variable named "id_DispSocket" that stores the id of the device with socket_B or socket_A relative to the alias of the socket that offers the resource through the socket-proxy;
a record type to define the access permission called "permission_A ^G " that defines a broad security context by granting the possibility of access by a group of users from device_A to socket_A and comprising:
or a variable called "id_Group" that stores the id of the group of users of the operating system of device_A,
or a variable named "alias" that stores the alias of socket_A, and
or a variable named "socket" that stores the value of socket_A;
a software module called connection-broker used to keep a record and control over the proxifications made and the accesses to them on device_A, being able to close them if they are inactive;
a pool of local addresses of device_A reserved specifically for this system and that are protected when the operating system of device_A starts up by the network framework at the request of the proxy-firewall server by means of the following general rules:
or a general rule of packet marking that determines to eliminate any possible marking of network packets in any communication, produced between local sockets of device_A, with local addresses belonging to the reserved local address pool;
or a general rule of packet filtering that determines to discard any packet with origin and destination a local socket of device_A that lacks a marking, as long as any of the sockets uses a local network address belonging to the reserved local address pool; and
or a general packet filtering rule that determines to discard any packet with a local address from the local address pool reserved for this method that has a non-local address as source or destination;
• a type of security context called "strict security context" carried out by a network framework configuration that marks the traffic packets using the con_Id assigned in the access_register relative to the target protected socket of device_A, the user source of communication also from device_A and permission_A ^U that enables access_register;
• a type of security context called "broad security context" carried out by a network framework configuration that marks the traffic packets using the con_Id assigned in the access_log relative to the target protected socket of device_A, and the group of the user originating the communication also of device_A and permission_A ^G that enables access; and
• a connection-broker database configured to store different types of records that include: socket_register, access_register, access_register_A, permission_A ^U and permission_A ^G.
[13]
13. The system of claim 12, where the devices use a POSIX-type operating system, also uses a proxy client and a stand-alone proxy server based on the secure SSH protocol and where Netfilter, the network framework used, performs packet marking and filtering using the TOS field of the IP protocol.
[14]
The system of claims 12 and 13, wherein a device_B also has a proxy-firewall server that allows including in profile_B ^A configuration aspects that extend the control that the proxy-firewall server of device_A has over all modules. software for device_B to facilitate the development of services that involve system calls, such as updating software modules for device_B.
[15]
The system of claims 12 and 13, in which socket_B of device_B offers a resource using the HTTP protocol and device_A uses a proxy as an HTTPS-HTTP type software module to be able to accept and process external communication requests towards the protected socket that is served in HTTPS, also includes: the configuration of a wildcard SSL certificate to protect the main domain from the HTTPS-HTTP proxy of device_A and all its possible subdomains;
the configuration of a web server on device_A to be able to redirect the communication request of the socket_B resource transparently to the main URL of the HTTPS-HTTP proxy, taking advantage of the subdomains as fields to identify the socket-proxy destination of said request and using as subdomains the alias of socket_B and the identifier of device_B; and
an adequate configuration of the HTTPS-HTTP proxy that allows obtaining from the request headers the credentials required to validate it and removing them from it before transmitting it to the proxy socket.

类似技术:

---

公开号 | 公开日 | 专利标题

---

ES2673938T3|2018-06-26|Procedure and network element for improved access to communication networks

---

US10706427B2|2020-07-07|Authenticating and enforcing compliance of devices using external services

---

ES2359637T3|2011-05-25|FIREWORKING SYSTEM TO PROTECT A COMMUNITY OF APPLIANCES, PARTICIPATING SYSTEM APPARATUS AND METHOD FOR UPDATING THE FIREWORKING RULES INSIDE THE SYSTEM.

---

ES2844248T3|2021-07-21|Method and device for data processing and communication system comprising such device

---

Alliance2013|Lightweight machine to machine technical specification

---

US9198038B2|2015-11-24|Apparatus and methods of identity management in a multi-network system

---

US7886335B1|2011-02-08|Reconciliation of multiple sets of network access control policies

---

US9258278B2|2016-02-09|Unidirectional deep packet inspection

---

US9210128B2|2015-12-08|Filtering of applications for access to an enterprise network

---

US20210144015A1|2021-05-13|Accessing hosts in a computer network

---

Keromytis et al.2003|The STRONGMAN architecture

---

Fremantle et al.2016|Oauthing: privacy-enhancing federation for the internet of things

---

US20180198786A1|2018-07-12|Associating layer 2 and layer 3 sessions for access control

---

Rios et al.2017|From SMOG to Fog: a security perspective

---

EP3328023A1|2018-05-30|Authentication of users in a computer network

---

US10523445B2|2019-12-31|Accessing hosts in a hybrid computer network

---

ES2794723A1|2020-11-18|Secure communication method and system using network socket proxying

---

El Jaouhari et al.2017|Security issues of the web of things

---

Carrozzo et al.2018|Interoperation of IoT platforms in confined smart spaces: the SymbIoTe smart space architecture

---

Mudugodu Seetarama2017|Secure device bootstrapping with the nimble out of band authentication protocol

---

Díaz García et al.2020|Multiprotocol Authentication Device for HPC and Cloud Environments Based on Elliptic Curve Cryptography

---

ES2411579B1|2014-08-08|SYSTEM AND PROCEDURE FOR USER CREDENTIALS CONTROL FOR ACCESS TO THIRD PARTY SERVICES IN MOBILE NETWORKS

---

EP3681185A1|2020-07-15|Communication server and method for secure authentication and identification of a device with an internet platform

---

Chifor et al.2021|IoT Cloud Security Design Patterns

---

Djin2005|Technical Report TR2005-544 Department of Computer Science

同族专利:

---

公开号 | 公开日

---

EP3800564A4|2021-06-02|

---

WO2019059754A1|2019-03-28|

---

US20210218708A1|2021-07-15|

---

WO2019059754A9|2020-05-22|

---

EP3800564A1|2021-04-07|

---

US11050716B1|2021-06-29|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

---

US10637724B2|2006-09-25|2020-04-28|Remot3.It, Inc.|Managing network connected devices|

---

US9350644B2|2012-04-13|2016-05-24|Zscaler. Inc.|Secure and lightweight traffic forwarding systems and methods to cloud based network security systems|

---

US9668834B2|2013-12-20|2017-06-06|Biomet 3I, Llc|Dental system for developing custom prostheses through scanning of coded members|

---

US9985930B2|2016-09-14|2018-05-29|Wanpath, LLC|Reverse proxy for accessing local network over the internet|

---

US10659433B2|2016-11-30|2020-05-19|Salesforce.Com, Inc.|Encrypting and securing data with reverse proxies across frames in an on-demand services environment|

---

法律状态:
2020-11-18| BA2A| Patent application published|Ref document number: 2794723 Country of ref document: ES Kind code of ref document: A1 Effective date: 20201118 |

优先权:

---

申请号 | 申请日 | 专利标题

---

PCT/MX2018/050013|WO2019059754A1|2018-06-03|2018-06-03|Secure communication method and system using network socket proxying|

---